Many services provided through the Internet require that the user first be authenticated before the services can be provided. Authentication is the process of attempting to verify the identity of the sender of a communication. The sender being authenticated may be a person using a computer, a computer itself or a computer program. For example, when accessing a bank account, a user may be required to log in by providing a username and password combination before the bank records can be accessed. Traditionally, a single service provider both authenticates the user and provides the service.
This centralized model has led to a proliferation of disconnected online user identities, and reduces privacy and convenience of users. Privacy is compromised when a user is asked to identify himself to the service provider for even minimal privileges. Each service provider may therefore maintain private information regarding the user which is subject to theft or misuse. Furthermore, the task of managing multiple usernames and passwords for various online activities is cumbersome at best.
To overcome the disadvantages associated with the traditional centralized model, the federated model has been proposed and implemented by various entities, such as the Liberty Alliance Project (LAP) and the OASIS WS-Security and associated Web Services Interoperability Organization (WS-I). Protocols developed by these organizations allow a web service provider to delegate authentication and/or authorization tasks to a trusted identity provider. This improves the convenience and privacy of the user e.g., by providing a single sign-on (SSO) capability, and gives the user more control over personal information.
FIG. 1 shows an exemplary implementation of a web service federation 10. In this example, user 12 accesses web service consumer (WSC) 14. WSC 14 may be an Internet portal providing weather, stock information, banking information to user 12 via an Internet connection 15. Alternatively, WSC 14 may be an application such as a video-on-demand device for accessing streaming multimedia content. Web service provider (WSP) 16 provides the data while identity provider (IDP) 18 authenticates user 12 and/or WSC 14, depending on the authentication requirements of the WSP. WSC 14 has several choices when invoking a WSP. It could invoke the WSP on the user's behalf, in which case the WSP will verify the user's credentials. It could also invoke the WSP on the user's behalf but additionally present its own credentials, in which case the WSP will verify both. Alternatively, the WSC can invoke the WSP in its own right. When a WSC invokes a WSP in its own right, the WSC would have already satisfied itself on the user's identity and a relationship exists between the WSC and the WSP, e.g., brokered via the trusted authority 19, that allows the WSP to only verify WSC credentials. The trusted authority provides a registry for federation members and the services that they provide along with authentication requirements. The trusted authority therefore brokers trust between the WSC 14 and WSP 16. In LAP federations, it is referred to as a discovery service. It should be noted that from a lifecycle perspective, the trusted authority is not always required. For example, the WSP may be preconfigured with the correct and acceptable authentication mechanisms.
Each Internet connection 15 may comprise any of various technologies enabling secure communication. For example, Internet connections 15 may each comprise a transmission control protocol (TCP) connection over which messages are passed by hypertext transfer protocol (HTTP) with transport layer security (TLS), thereby providing a secured, encrypted connection over the Internet. TLS is the successor to the secure sockets layer (SSL) specification. It can be seen that for the web service federation to function, WSC 14, WSP 16, and IDP 18 must work together in what is known as a “circle of trust” 20. The phrase, “circle of trust” refers to a group of service providers and identity providers that have business relationships based on a federated architecture and operational agreements and with whom users can transact business in a secure and apparently seamless environment.
FIG. 2 shows a swimlane diagram 50 illustrating an exemplary transaction for supplying federated web services from WSP 16 to WSC 14 and user 12. Exemplary web services could include weather, stock, banking, or multimedia data. User 12 initially submits a request 52 to WSC 14. The request may be made over an Internet connection or locally. The WSC application then sends a SOAP message 54 to WSP 16 to invoke the service. A SOAP message is a message sent using the SOAP protocol, a well-known, widely available protocol for exchanging extensible markup language (XML) based messages over a computer network, typically on top of an HTTP layer. If WSP 16 requires authentication of user 12 prior to supplying the particular service requested, it may send a redirect message 56 to WSC 14, to redirect WSC 14 to IDP 18, for authentication.
WSC 14 then contacts IDP 18 and sends an assertion request 58. The request may include any of various identifying information from user 12, such as a username and password. If sufficient, IDP 18 responds with an assertion 60, including a security token. One example of such a security token is a Security Assertion markup Language (SAML) security token, which is a signed message that can be authenticated by WSP 16. The federation specifications and the identity provider will specify what types of security tokens are available. WSC 14 then sends a new invoke message 62, this time including the security token, which assures WSP 16 that user 12 is sufficiently authenticated by IDP 18, which issued the token.
It should be noted here that WSP 16 does not require a separate username and password of user 12, and the username and password need not be stored with the WSP 16. Any number of WSPs can work with IDP 18 to obtain such authentication. Furthermore, the assertion requested and delivered by IDP 18 may be limited to specific facts about the user, rather than the user's actual identity. This is sometimes referred to as a blind credential. For example, if the web service is simply providing a weather forecast, the assertion may provide that the user has authorization to view the weather forecast, and further, the user's zip code (or other geographical identifier such as a city name) so that the weather forecast can be tailored to the user's geographical location.
LAP architecture currently includes specifications for over 20 different security token types and WS-I architecture supports four security toekens. Some of the security tokens supported by LAP and WS-I are SAML security tokens. Each token type can provide a different type of security mechanism, from no additional security (relying instead on the underlying SSL/TLS on top of which HTTP and other transfer protocols are provided) to very strong security. A variety of security mechanisms are therefore implemented using the various SAML security tokens. This provides flexibility according to need. For example, stronger SAML security tokens provide enhanced security for protecting sensitive information, while weaker SAML security tokens require fewer resources. The level of security can therefore be tailored to the sensitivity of the information being provided to or from the WSP.
Since LAP, WS-I, and other security standards bodies only provide specifications for the protocol and schema specifications for interoperation between the WSC and the WSP, there is a gap in terms of how the web services manage security. Currently, federation protocols are hard-wired into the business logic at both ends of the conversation. This causes difficulties during the lifecycle of the web service provider due to changes in security needs or when new security mechanisms are created. As a result, a large cost is incurred in manually redeploying an application when new or different security mechanisms are required to be incorporated therein.
Therefore, a deployment tool and processes are needed that ease the adoption of the latest security technologies to protect both existing web services as well as new web services. Such a system should be less error-prone and protect security at both ends of a WSP and WSC interaction, as well as enable easy management of the lifecycle of a web service from a security perspective.